In accordance with the previously-existing state of the art, a user can utilize the Internet to access Web sites hosted on remote computers (e.g., Site Server A, Site Server B, etc.). See FIG. 1.
In this situation, the user typically accesses a remote Web site using a standard electronic access packet. See FIG. 2. The standard access packet has an architecture which includes header contents and body contents. Header contents typically include information such as the target site's IP ("Internet Protocol") address, the user's browser type, the date and size of the packet, etc. Body contents typically includes destination information, return co-ordinates, etc.
At the destination site, additional user-specific information may be collected, e.g., the user's name, the user's postal code, the user's telephone number, the user's selections from various menu choices, etc. When the destination site communicates back with the user, this additional user-specific information may, if desired, be added to the body content of the access packet, so as to establish a "state" for the user, and this "state" can be maintained and used during the user's session with that destination site.
In accordance with the previously-existing state of the art, if and when the user thereafter moves from the first destination site to a new destination site, either by "clicking" on a hypertext link presented by the first destination site or by entering a new URL ("Universal Resource Locator") address (i.e., "http://www.xxxxxxxx.xxx") into the user's browser, the user logs onto the new site using the standard access packet, thus arriving at the new site "without state".
The architecture employed by the previously-existing state of the art can be advantageous in the sense that site access on the Web is simple and "egalitarian". However, it can also be limiting in the sense that the user must establish "state" at each new Web site as that site is accessed by the user.
Numerous situations exist where it could be advantageous to have "state" information carried from one Web site to another Web site.
By way of example but not limitation, it could be advantageous to have "state" information carried from one Web site to another Web site when accessing some Web commerce sites. More particularly, some Web commerce sites utilize a so-called "shopping basket" transaction engine, wherein the user shops from a "store list" of available products and selects the desired products for the user's "shopping basket". In many of these systems, the user may require more detailed information about a particular product before selecting that product for purchase. As a result, the system may be configured to permit the user to temporarily exit the store list setting to view specific product information before returning to the store list setting to resume product purchasing. In such a situation, it can be desirable to enable the user to select the product for purchase while in the product information setting, and to have this purchase selection retained upon the user's return to the store list setting. Furthermore, in some situations, it may be desirable to have the store list setting hosted by one Web site and specific product information settings hosted by one or more other Web sites, e.g., sites maintained by specific manufacturers. This is particularly true inasmuch as each individual manufacturer is generally the party most familiar with its own products. In this situation, it would be helpful for the user to establish "state" at the store list site and then to retain, and "enhance", that state as the user moves to and from various product information sites.
By way of further example but not limitation, it could be advantageous to have "state" information carried from one Web site to another Web site when accessing some Web education sites. More particularly, in such a Web education site, student registration information might be maintained at a first site, educational content might be maintained at a second site, and an interactive test system might be maintained at a third site. In this situation, it could be helpful for the user to establish "state" at the first registration site, go to the second educational content site and "enhance" that state, e.g., by reviewing educational material, and then go to the third interactive test site for testing and use the test results to further "enhance" the user's state, e.g., by taking a test and recording the results of that test.
By way of further example but not limitation, it could be advantageous to have "state" information carried from one Web site to another Web site when accessing some Web engineering sites. More particularly, in such a Web engineering site, basic information might be maintained at a primary site regarding the interactive design of a product, while component details might be maintained at one or more satellite sites. In this situation, it might be considered more efficient for the user to specify components at a satellite component site and let the information regarding the specified components travel back to the primary site as enhanced state information upon the user's return to the primary site.